같이달램 배포 후기
🏆 프로젝트 목표
부트캠프에서 진행한 프로젝트인 같이달램 프로젝트에 배포를 맡고 인프라를 구축하고 배포 자동화를 위한 CI/CD 설계
📅 스케쥴
2024.9.9 ~ 2024.10.21(한달 반가량)
✅ 프로젝트에 대한 전반적인 경험
왜 Vercel을 선택하지 않고 AWS를 선택하였는가? 에 대한 물음을 하면 기능적인 대답보다는 개발자로써 해보는게 조금 더 성장할 것 같다. 혹은 안 하는것이랑 못 하는것은 다르니 경험 해보는게 좋을 것 같다. 등 어떤 차이가 있는지 왜 필요한지 에 대한 설명 보다는 배움에 이유를 두고 선택을 했던 것 같다.
그렇다면 두개의 차이점에는 배포 자동화에 빠르고 간편한 호스팅 서비스를 제공하는 Vercel에 비해 AWS는 확장성과 더 엄청 방대한 AWS만의 웹 호스팅 서비스를 이용 할 수 있다는 점이다.
그리고 Vercel의 서버는 서버리스로 동작하나 AWS의 EC2같은 경우에는 24시간 동작한다
참고로 서버리스로 동작하는 서버에는 Cold Start 라고하는 요청이 없다가 요청이 들어오는 경우에 초기 속도에 영향을 주는 단점이 있다 하여 Vercel로도 서비스를 열어보고 AWS로 동작하는 웹 페이지와 비교를 해보았었는데 사이트의 크기가 적은지 큰 차이는 내보이지 못했지만 AWS로 동작하는 웹페이지가 정말 미묘하게 조금 더 빨랐던거같다
하나 더 해서 Vercel도 결국 AWS 위에서 동작하는 호스팅 서비스라 AWS보다 가격이 비쌀수있다는 점이 있었다. 그렇기 때문에 AWS를 선택하여 배포하기로 해보고 어떠한 방식으로 설정하였는지 어떠한 트러블슈팅이 있었는지에 대해 설명 하고자합니다.
AWS의 기초 설정
Next.js를 사용하여 웹사이트를 개발할 예정입니다. 이에 따라 크게 두 가지 배포 방식을 고려했습니다
- EC2를 사용하여 가상 서버를 구축하는 방법
- CloudFront, S3, 그리고 Lambda를 조합하여 서버리스 아키텍처로 SSR(Server-Side Rendering)을 구현하는 방법
그러나 서버리스 방식을 택하면 Vercel과 크게 차이가 없다 생각하고 24시간 서버에 대한 궁금증이 몇가지 있었기에 첫번째 방법을 택했습니다.
사용한 서비스
사용한 서비스에는 AWS의 계정을 관리할 IAM AWS의 상태를 보고해주고 특정 조건에 어떤 행동을 해줄 트리거 서비스이자 감시 서비스인 CloudWatch 도메인 이름 서비스인 Route53등을 사용하였고
부가적으로 Web Server로 Nginx 편리한 관리를 위한 PM2 SSL 인증을 위한 certbot등을 사용했습니다.
ec2
Ubuntu
- 많은 사람들이 사용하는 만큼 안정적이고 신뢰할수있는 os이기 때문 다양한 레퍼런스들이 많아서 접근하기 비교적 쉬웠기에 우분투 서버를 선택하였습니다.
인스턴스 설정
인스턴스 유형: t2.micro (프리티어)
페어: PEM
인바운드 설정 : 8080 (어플리케이션 서버), 80 (HTTP),4 43 (HTTPS), 22 (SSH)
스토리지 구성: 데이터 저장소로 사용
서버 접근 및 초기 설정
- SSH로 서버 접근:
ssh -i [키 파일 경로] [사용자명]@[퍼블릭 IP] - 기본 소프트웨어 설치:
- Node.js
- npm
- git clone
이렇게 인스턴스를 생성하고 SSH 연결을 통해 가상 서버에 접근하여 기초적인 세팅을 해주었습니다.
CI/CD
AWS CodePipeline vs GitHub Actions
AWS에 배포하고 관련 서비스를 사용하다 보면 CI/CD와 관련된 서비스도 지원함을 알 수 있습니다. AWS CodePipeline은 AWS 인프라에 쉽게 배포할 수 있고 시각적인 UI를 제공합니다.
하지만 AWS CodePipeline은 AWS 생태계에 종속되고 사용량에 따른 비용이 발생할 수 있다는 단점이 있습니다.
반면 GitHub Actions는 GitHub를 저장소로 사용한다면 쉽게 접근할 수 있습니다. 저장소와 원활하게 통합되며, 다양한 참고 자료가 있고 학습 곡선이 CodePipeline보다 낮습니다. 또한 공개 레포지토리라면 무료로 사용할 수 있어, 이를 활용하여 CI/CD 환경을 구축했습니다.
CI/CD YAML 파일 구성
YAML 파일은 최종적으로 3개로 구성했습니다:
- push나 pull request 후
yarn build를 실행하여 정상적으로 빌드되는지 확인하는 파일 - 버전이 올라갈 때 Sentry에 새로운 소스맵을 업로드하고 릴리스를 생성하여 버전별 오류 추적을 용이하게 하는 파일
- main 브랜치로 push 됐을 때 SSH 연결로 접근하여 파일을 가져오는 파일
이렇게 구축하여 빌드 테스트, 오류 추적, 배포 관련 자동화 작업을 수행할 수 있게 했습니다.
3번 YAML 파일은 main으로 push 됐을 때 22번 포트를 사용하여 Ubuntu 서버에 접근, 지정된 git 주소로 git pull origin main 명령어를 실행 후 yarn, yarn build 과정을 거치고 pm2 명령어를 통해 8080 포트로 서버를 실행시키는 구조로 만들었습니다.
이때 정상적으로 구성이 되는지에 테스트를 해보다 첫번째 이슈가 터지고 말았습니다.
인스턴스가 빌드 과정에서 빌드가 정상적으로 되지않는 이슈
생각보다 해당 이슈는 외국 포럼이나 많은 케이스를 내고 있던 사례였기에 찾아보고 시도해보고 해결해보는 과정에서 성장할 수 있었다고 생각합니다.
그리고 자잘한 이슈로는
같이 달램 프로젝트 도중 프로덕션 환경 이미지파일 누락 이슈
같이 달램 프로젝트 도중 프로덕션 환경에서 환경 변수 주입 이슈등이 있었습니다
📚 참고한 웹이나 문서 (선택)
배포환경에서 인스턴스가 정상적으로 되지않는 이슈를 다룬 레딧 링크
Next.js AWS 배포를 다룬 가이드 글
Next.js 빌드시 파일 구조에 대한 설명이 담긴 글